home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15907 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: gaia.ns.utk.edu!mbk
  2. From: mbk@caffeine.engr.utk.edu (Matt Kennel)
  3. Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.c++,comp.lang.java
  4. Subject: Re: The Good, the Bad, the Ugly, and the Wicked ...
  5. Followup-To: comp.lang.smalltalk,comp.object,comp.lang.c++,comp.lang.java
  6. Date: 8 Apr 1996 19:40:42 GMT
  7. Organization: University of Tennessee, Knoxville and Oak Ridge National Laboratory
  8. Message-ID: <4kbq3q$1i8@gaia.ns.utk.edu>
  9. References: <31570B8E.5A12@vmark.com> <4je5rq$7qg@mimas.brunel.ac.uk> <4jes0t$gth@decaxp.HARVARD.EDU> <31630E30.5A02@oma.com>
  10. Reply-To: kennel@msr.epm.ornl.gov
  11. NNTP-Posting-Host: caffeine.engr.utk.edu
  12. X-Newsreader: TIN [version 1.2 PL2]
  13.  
  14. Robert C. Martin (rmartin@oma.com) wrote:
  15. : It is neither wrong nor right.  There are certainly some real-time systems
  16. : that are incompatible with certain GC strategies.  There may indeed
  17. : be some real-time applications that are incompatible with *any* GC
  18. : strategy, (other than manual GC).
  19.  
  20. : In any case, it matters little.  The more intense the real-time
  21. : constraint, the more work the engineer will have to go through
  22. : to manage the automatic garbage collector.  (e.g., turning it on or off,
  23. : throttling it, forcing unscheduled collections, etc.)  Thus, eventually
  24. : one merely trades the job of managing memory, for the job of
  25. : managing the collector.
  26.  
  27. It is not a trade, as nearly all garbage collection systems still
  28. *allow* manual memory management.
  29.  
  30. A garbage collector provides a potential solution that is very difficult
  31. to do without. 
  32.  
  33. : > It has also been pointed out by people who appear understand
  34. : > g.c. that non-g.c. systems such as C cannot be inherently relied
  35. : > upon in real-time applications; calls to the memory allocation
  36. : > system (malloc or new) may not have defined time bounds.
  37.  
  38. : Malloc and new can *always* be made to be deterministic.  That is
  39. : one of the major attractions to manual memory management in 
  40. : real time systems.  You can use malloc/free (new/delete) pairs which are
  41. : 100% predictable.
  42.  
  43. Are they?  Have you gone through the all the possible orderings of
  44. previous 'new' and 'malloc' so that you ***KNOW*** exactly
  45. what the internal heap structures are so that subsequent calls to 
  46. 'malloc' and 'new' and 'free' take a known amount of time?
  47.  
  48. The point is that standard library malloc and new are themselves already
  49. one level of 'automatic' storage allocation compared to fixed 'Fortran'
  50. blocks of storage and have potentially harmful real time implications. 
  51.  
  52. Thus the distinction should not be "GC" vs "malloc" but really
  53.  
  54. "GC or malloc" vs "static fixed storage."
  55.  
  56. If you accept 'malloc' you are relying on some automatic procedure already.
  57.  
  58.  
  59.